.\" Use -mm macros
.ds Rh 1003.6: Security Extensions
.ds Au Ana Mar\o'i\(aa'a de Alvar\o'e\(aa' <anamaria@sgi.com>
.ds Dt January 7-11, 1991
.ds Lo New Orleans, LA
.ds Ed Jeffrey S. Haemer <jsh@usenix.org>
.ds Wd U\s-3SENIX\s0 Standards Watchdog Committee
.if '\*(Su'' \{\
.ds Su the \*(Dt meeting in \*(Lo:
.\}
.if n \{\
.tm Subject: Standards Update, \*(Rh
.tm From: \*(Ed
.tm Reply-To: std-unix@uunet.uu.net
.tm Organization: \*(Wd
.tm
.\}
.S 12
.TL
An Update on U\s-3NIX\s0\u\s-41\s0\d-Related Standards Activities
.FS 1.
UNIX\u\(rg\d is a Registered Trademark of UNIX System Laboratories
in the United States and other countries.
.FE
.nr :p 1
.sp
\*(Rh
.AF "\*(Ed, Report Editor"
.AU "\*(Wd"
.MT 4
.if n \{\
.nh
.na
.\}
.PF "'\*(DT Standards Update'     '\*(Rh'"
\*(DT
.sp
.P
\fB\*(Au\fP reports on \*(Su
.P
.HU "Overview"
The P1003.6 group met for the entire week.
Our main task was preparing draft 8 for mock ballot.
We also planned for P1003.6 test assertions
and discussed file locking,
manipulating or duplicating the information in opaque data objects,
and allowing \fIps\fP
to show privileges and \s-1MAC\s0 labels of processes.
.P
We also heard two proposals at the meeting,
one on Privileges and one on Discretionary Access Control,
which I discuss in the relevant subgroup sections, below.
.HU "Mock Ballot"
P1003.6 plans to go to mock ballot
after our April meeting.
We will review comments at the July meeting,
and try to ballot the document soon afterwards.
The October meeting will be used for ballot resolution and clean-up.
.P
To prepare for mock ballot,
the working group submitted written comments on the current draft,
and subgroups spent the week addressing them.
Commenters included
Chris Hughes (\s-1ICL\s0),
Roland Clouse (Unisys),
Dan Ujihara (\s-1SUN\s0),
and me (\s-1SGI\s0).
.HU "Test Assertion Plans"
The group decided to create a separate test-assertions document
that parallels the current document.
Each subgroup will be responsible for its own test assertions,
and will ensure that the assertions document
and the main document remain consistent.
(I.e., any updates to the P1003.6 document
will trigger changes to the assertions document.)
Dave Rogers (Data Logic) and I are co-chairing this effort.
If you are interested in helping to write test assertions,
please let us know.
.HU "Opaque Security Data Object Duplication"
Duplicating the information in opaque security data objects
\(em \s-1ACL\s0s, labels, and privileges \(em
presents three distinct kinds of problems:
.AL
.LI
duplicating the information within a process,
.LI
passing the information between processes in a single system, and
.LI
exporting the information out of a system.
.LE
.P
Copying the information within a process is simple.
What's hard is copying it out of the process's context
\(em for example, for backups.
We decided that such exporting will require
passing out both object addresses and sizes,
as well as data characteristics,
such as \fIbinary\fP, \fItext\fP, or \fIfunction\fP.
.HU "Privileges"
John Griffith (\s-1HP/Apollo\s0) presented
a new privileges proposal that simplified
determining whether a process has, lacks, or inherits a privilege.
.P
In draft 8,
a process could only inherit privilege
if the ``allowed'' file-privilege attribute was set:
inheritance, through the inheritable group,
depended on restrictions provided by the ``allowed'' file privilege attribute.
.P
The subgroup agreed that this needed simplifying.
The newly agreed-on substitute is that
a privilege can be inheritable
if it exists in the inheritable group
or if the file's ``forced'' privilege attribute is on.
In other words, after an exec occurs, a
privilege that is on in the inheritable privilege group
can turn itself on in the permitted privilege group.
.P
The subgroup spent much of the remaining time
editing its part of the document.
Two issues I hope will be resolved next meeting are:
.AL
.LI
accommodating privileged shell scripts in the current proposal, and
.LI
determining how to store privilege information for later use.
.LE
.HU "Discretionary Access Control"
The new \s-1DAC\s0 proposal consisted of two documents
representing a collaborative effort by Paul Karger (\s-1OSF\s0),
Rand Hoven (\s-1HP/APOLLO\s0),
and Jon Spencer (Data General).
It tried to
simplify the way
default \s-1ACL\s0s and \s-1MASK\s0_\s-1OBJ\s0s work,
and it removed any requirement for \s-1MASK\s0_\s-1OBJ\s0 entries
when no additional \s-1ACL\s0 entries existed.
In the end,
we decided to retain the old scheme
but will try to shore up areas
that the new proposal pointed out were particularly weak.
The proposal's sponsors agreed to this,
providing the new draft offers a satisfactory alternative simplification.
.P
The subgroup also attacked the opaque object issue described earlier,
defining an interface
to interconvert \s-1DAC\s0 opaque objects and text strings,
and a relocatable \s-1ACL\s0 format
that can be stored in an audit record.
.P
The \s-1DAC\s0 subgroup will pass their draft to the full group
after the next meeting.
.HU "Mandatory Access Control"
The \s-1MAC\s0 subgroup
discussed the written comments to their section
and feel they will be ready for ballot after the next meeting.
.P
Two major issues arose:
.AL
.LI
whether our document should address special (block and character device) files,
and
.LI
whether we needed a \fIdup()\fP-like function to copy internal formats.
.LE
.P
The subgroup decided the current version of P1003.6
shouldn't address terminals or other special files,
but the second issue will be passed on to the entire group.
.HU "Audit"
The Audit subgroup discussed all the written comments
and will only need one more meeting to be ready for ballot.
Their work,
including mandatory record types,
will be based on \s-1X/O\s0pen's.
They will not address Portable Data Record Format,
and optional record types will be implementation-defined.
.P
Clearly, audit functions
will need both pointers to objects and their sizes
to operate on \s-1MAC\s0, \s-1DAC\s0, and Privilege opaque data.
Because of this,
I predict all three subgroups will have to provide interfaces
to provide the information.
.HU "Liaison .6/.7/.8"
The liaison group met again
to discuss areas of compatibility and overlap between our respective documents.
(The October P1003.6 snitch report sketches our ongoing agenda.)
We identified areas that P1003.6 (Security),
P1003.7 (System Administration),
and P1003.8 (\s-1TFA\s0) already handle,
areas we might handle,
and areas that are falling through the cracks.
After we finish identifying areas of concern,
we may write \s-1PAR\s0s for anything we cannot farm out to existing groups.
In April, we will discuss how to report our findings
back to the three groups.
